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When "Group Commit Timers and High-Volume Transaction Systems" was 
first published in the proceedings of the Second International 
Workshop on High-Performance Transaction Systems (Asilomar, 
California, September 1987), the graphs in Figures 4 and 5 were 
accidentally switched. The authors apologize for the error. In 
this publication, the. graphs are correct. 



GROUP COMMIT TIMERS AND HIGH VOLUME 
TRANSACTION SYSTEMS 

Pat Helland, Harald Sammer, Jim Lyon, Richard Carr, and Phil Garrett 
Tandem Computers, Inc. 

Andreas Reuter 
University of Stuttgart. 

1) Introduction 

In the summer of 1986, Tandem released the B30 version of its Transaction Monitoring 
Facility (TMF). This release included a GROUP COMMIT mechanism. It also included 
a primitive mechanism to gate the commit writes using manually adjusted TIMERS U]. 
Subsequent experiments on large benchmarks have shown that timers reduce the 
overhead of transactions running on high volume systems. This reduced overhead 
increases system throughput while meeting response time constraints. 

While other systems have used Group Commit TimersP], we have investigated the fact 
that various timer values are appropriate for various system loads. This paper discusses 
TIMERs and describes how a transaction's commit overhead is reduced by making it 
delay. It turns out that the system can set the timer dynamically to minimize average 
response time. Calculations for the optimal TIMER DELAY are presented. Finally, 
some directions for future research are described. 

2) Group Commit and Timers 

Group Commit refers to the technique used in high volume transaction systems where 
many transactions are committed with a single disk I/O to the log. That single I/O may 
contain commit records for several transactions. 

Group Commit has been in use for a number of years now [Gawlick] . Without group 
commit, the transaction rate of a single-log system would be limited by the number of 
transfers per second that the log could support Group Commit allows transaction 
systems with disk-based logs to break through that barrier of roughly 30 transaction per 
second. 

When Group Commit Timers are in use, the system behaves as follows: 

When a transaction needs to write a commit record it will wait. 

When the Group Commit Timer pops, all of the transactions waiting to get a 
commit record written will have a record written as a part of a single disk I/O to 
the log disk. 



We also define special behavior when the Group Commit Timer value is 0. This is: 

If a transaction needs to write a commit record and there is no log I/O 
outstanding, then the commit record is immediately written to the log. 

If a log I/O completes and other transactions are waiting to commit, then commit 
records for all waiting transactions are written using a single I/O. 

When non-zero Group Commit Timers are in effect, the system awakens periodically and 
writes commit records for all waiting transactions using a single I/O. The result is that 
commit writes occur at scheduled intervals. Non-zero Group Commit Timers are a lot 
like people waiting on the street corner for a bus that arrives every five minutes. When 
the Group Commit Timer is zero, the bus driver will leave when the first passenger 
arrives. 



3) Our Model 

We have chosen to examine the effect of Group Commit Timers on CPU response time. 
One could justifiably argue that this is inadequate because disk I/O and the effects of 
queuing for disk I/O have not been included. This has been done for the following 
reasons: 

• Since we have a single writer of the Log and the Log is kept on a separate 
disk from the database, queuing for I/O on the Log disk is negligible. 

• We believe that Group Commit Timers will not significandy affect the 
queuing for disk at a fixed transaction rate. 

• The response times that we use are for comparison purposes only. We 
intend to minimize the time that a transaction spends queued for the CPU 
and utilizing the CPU. 

• Most importandy, we were getting a headache understanding this much. 

Fundamentally, we are assuming that Group Commit Timers do not affect the I/O 
component of the response time. We hope to see further extensions of this work which 
incorporate disks and disk queuing into the model. 



4) 



Motivation 



Timers cause individual transactions to be delayed. Intuitively, this also implies an 
increase in the transaction's response time. Surprisingly, timers can reduce the average 
transaction's CPU response time by reducing the per-transaction overhead. 

To understand this, one must realize that transactions spend much of their time waiting in 
the CPU queue. By reducing the total demand for CPU resources, we reduce the length 
of the queue. The time that a transaction waits in the queue can be dramatically reduced 
if the CPU is heavily loaded. 

Group Commit Timers cause the number of transactions in each Group Commit Buffer to 
increase. The number of Group Commit writes drops. This decreases both the average 
CPU cost for each transaction and the total CPU work performed by the system. As the 
total system CPU work drops, so does the queue length for the CPU and the average 
response time for a transaction. If the savings in CPU queuing exceeds the average wait 
time for the Group Commit Timer, then Timers improve the transaction's response time. 
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Response Time vs. Timer Value 

Note that as the timer values increase, the time spent for the 
transactions work (including CPU queuing) drops. 



The remainder of this paper is organized as follows: 

Section 5 describes the technique for calculating the average response time of a 
transaction when the Group Commit Timer is zero. 

Section 6 describes how transaction response times are calculated in a system in which 
timer values are non-zero. 

Section 7 discusses a technique by which timer values may be automatically determined 
as a function of measurable system parameters. 

Section 8 describes how to calculate all of the necessary parameters for the equations 
from the system. This allows the system to plug in values to the described equations and 
set the timers dynamically. 

Section 9 presents some predictions of the effect of Group Commit Timers on various 
transaction loads.. 

Section 10 consists of a brief description of the use of the Group Commit Timers at 
Tandem. 

Section 1 1 discusses areas in which we feel further research may be beneficial. 

Finally, Appendix A contains all of the mathematics necessary to derive the formulas 
presented. If you trust our math, the appendix may be skipped. 

5) Response Time With Zero Timers 

Before examining the expected response times for transactions when timers are non-zero, 
it is important to analyze the behavior of transactions when the Group Commit Timers 
are zero. In this discussion, as in the rest of the paper, we examine the total time spent by 
the transaction either executing in the CPU or waiting in the CPU queue. The time for 
the physical I/Os to the database has been omitted. We are assuming that Group Commit 
Timers do not affect the I/O time. 

Let's divide the transaction into two parts to examine the CPU costs associated with it. 
We choose to consider the transaction's CPU cost as the sum of: 

A -The CPU cost of a transaction (excluding COMMIT). 

B -The CPU cost for one transaction's COMMIT (i.e. the cost to write a Group 
Commit Buffer). 

Both A and B are measured in seconds. 



Define: 

Co - The average number of transactions in a Group Commit Buffer when a timer 
value of zero is used. 

T - The transaction rate (transactions per second). 

Uo - The CPU utilization of a system when no timers are used. 

Ro - The average transaction's CPU response time on a system when the timer has a 
value of zero. 

We can now calculate CPU utilization by determining the amount of work for each 
transaction times the number of transactions per second. The utilization is dimensionless. 

Uo = (A + B / Co) * T 

Next, assuming M/M/l queuing gives us a response time for a transaction of: 

(CPU Work) 

CPUResponseTime = seconds. 

(1 - utilization) 

This means that the transaction's average CPU response time (that is, its response time 
exclusive of I/O) will be: 

(A + B) 

R = seconds. 

(1 - Uo) 

This can be rewritten as: 

(A + B) 

Ro = seconds. 

(1 - T(A + B / Co)) 

5.1) Calculating C 

Unless B is small with respect to A, the calculation for the average transactions response 
time will be highly dependent on Co (the fullness of the Group Commit Buffer). To 
understand the calculation of Co. we must review what can cause a Group Commit Buffer 
to be written. 

There are two reasons why a Group Commit buffer would be written when the timer is 
zero: 

~ If a transaction is ready to commit and no I/O is in progress. 

~ If an I/O completes and a transaction is waiting to commit. 



Let's define the following terms: 

L - The amount of time it takes a Log I/O to complete. This time is wall clock time 
rather than CPU time. We are not including queuing for the disk. 

W t - The total writes to the log per second. 

W { - The immediate writes to the log per second. These are the writes caused by the 
transaction arriving and finding no I/O to the log in progress. 

W d - The delayed writes to the log per second. These are the writes caused by an I/O 
completing with one or more transactions waiting. 

Cod - The average number of transactions in a delayed write buffer. 

Note that: 

W, = Wj + W d 

Now, we remember that each immediate write will have one transaction in each buffer. 
Each delayed write will have Cod transactions in each buffer. So, now we can state that: 

Wj+ WdCod 

C = 

W, 

After much gnashing of teeth, this becomes: 

Co = LT + e-LT (see Appendix A. 1) 

As you can see, when the timer is zero, the number of transactions in a Group Commit 
buffer is a function of the transaction rate and the time a write to the log takes. It is 
completely independent of any other factors. For this reason, it is possible to pick a 
reasonable time for the log write and chart Co as a function of transaction rate. See figure 
2. 
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Zero-Timer Group Commit Buffer Size 
with L = .033 seconds 



6) Response Time With Non-Zero Timers 

The calculation of the system utilization and transaction response time follows the same 
pattern for systems using non-zero timers as it does for systems with zero timers. There 
are two differences: we expect the utilization to be different and the response, time with 
non-zero timers must include an expected wait for the timer to pop. Let's define: 

D - The timer delay (in seconds). Every D seconds, the timer will pop and a Group 
Commit Buffer write will be attempted. 

d - The average number of transactions in a Group Commit Buffer when timers are 
non-zero. 

U d - The CPU utilization when timers are non-zero. 

R4 - The average transaction's CPU response time when timers are non-zero. 

We can now state that: 

U d = (A + B/C d )*T 

(A + B) 

R d = + D/2 seconds. 

(1 - Ua) 

In a system using non-zero Group Commit Timers, there is only one reason for writing a 
Group Commit Buffer, the timer pops, and at least one transaction needs a commit record 
written. 

We must determine Cd to be able to evaluate this. 

6.1) Calculating C d 

To evaluate Q, we must first discuss the conditions under which a Group Commit buffer 
will be written. When the timer pops (every D seconds), the Group Commit buffer will 
be written to the log if one or more transactions are waiting to write a commit record. All 
of the waiting transactions will be included in the buffer. We are assuming that a full 
buffer is so unusual a condition as to be negligible. 

What we must be careful to consider, however, is the probability that the timer will pop 
and there will be no transactions waiting to be committed. The Group Commit buffer 
will not be written under those circumstances. 

To evaluate this probability, we use a Poisson distribution. We represent the probability 
that exactly n transactions are waiting for a commit record to be written as: 

Ptd(h) 

where TD is the transaction rate (T) times the delay interval (D). This represents the 
expected mean number of transactions. 



We can now describe the expected number of records written in a Group Commit buffer 
as: 

oo 

£ IPtdO) 
i-i 

The probability that a Group Commit write will occur is the same as the probability that 
at least one transaction is ready to commit when the timer pops. This is: 

IPJ) 
1*1 

So, the average number of transactions in a Group Commit buffer will be: 
Expected records per write 



c d = 


Probability that a write occurs 


Which is: 






I iPjoO) 

;_1 


C d = 


1=1 


I PtdO) 

i=1 


Which boils down to become: 


r. ,- 


TD 



(see Appendix A.2) 
1 - e-TD 

Now that we know how to calculate the average response time, what do we do with it? 
Our goal is to employ the timer mechanism in such a way that it minimizes the average 
transaction's response time. If we can derive a formula based on information available in 
the system, we can construct an algorithm to set the timers dynamically, based upon the 
system load. 



7.1) Minimizing Response Time 

The average response time for a transaction (excluding I/O) when timers are in use is: 

(A + B) 

Rd = + D/2 seconds. 

(1 - U d ) 

Our goal is to rearrange this formula to be a function of: 

T - The transaction rate of the system. This toe can directly measure as the system 
operates. 

B -The cost of writing a Group Commit Buffer. This is a constant cost on a given 
system. Its value is determined by using performance measuring tools. 

A - The average transaction's CPU cost (excluding the cost of commit). This we can 
calculate as a function ofB, T, measured CPU utilization, and measured rate 
of writing the Group Commit Buffer. 

D - The Group Commit Timer Delay. 

Once we have this formula, we then assume that B, A, and T are constants with respect to 
Rd. The calculation of Rd can then be viewed as a function in terms of D. The minimum 
value of Rd can then be found by taking its derivative and solving for: 

R d ' = 

This strategy'gives us: 

DA + DB 

Rd = + D/2 (see Appendix A.3) 

D - TAD -B +Be-TD 

B(A + B)(TDe-TD - 1 + s-td) 

d > +1/2 

(D - TAD - B + Be-TD)2 

(see Appendix A.4) 

If we assume that Rd' = 0, we can then derive that: 

B(1 - e-TD) + V(2B(A + B)(1 - e' TD -TDs-td) ) 



D = 



1 - TA 

(see Appendix A.5) 



This is the formula that defines the proper value for a Group -Commit Timer. 
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7.2) Computing the Optimal Timer Delay (D) 

As we have just seen, D may be expressed as: 



B(1 - e-TD) + V( 2B(A + B)(1 - e' 10 -TDs-td) ) 

D= 

1-TA 

Unfortunately, this solution for D involves D in the right half side of the equation. We 
have chosen to determine a method to guess at an initial value for D and then refine the 
guess to be within acceptable limits. 

When we solved for D, we did so assuming that FV = 0. We then rearranged the 
function to arrive at a value for D. In doing so, we really arrived at a different function Y 
which we know has the same value for D at the point Y = 0. It is important to realize that 
the function Y is not really the same as Rd*. We have chosen as Y the function: 

Y = 2B(A+B)(TD©-td -1 + 6 -td) + (D - TAD - B + Be-TD)2 

(see Appendix A. 6) 

Once we have an initial guess for the value of D, we will use the function Y to find a 
better guess. The Newton-Raphson methodtPRESs] extrapolates to find the next estimate 
of the root that we are searching for. This is done by geometrically extending the tangent 
line at the current point Y(Dj) until it crosses zero. This then becomes our next guess 
Y(D i+1 ). 

So, to iterate, we have the equation: 

Y(Di) 



D i+i = Di 



Y'Pi) 

To do this we need Y'. We have concluded that this is: 

Y' = 2( (1 - TA)D - B(1 - e-TD)) (1-TA - TBe-TD) 

- 2B(A + B)T2De-TD 

(see Appendix A.6) 

For our initial guess, we will assume that TD is large. This causes e -td to approach zero. 
We will take as our guess the value of D when e - TO is zero. This gives us: 

B + V2B(A + B) 

D = 

1 -TA 

So, to calculate the optimal timer values, we will first calculate D using the above 
formula. We then calculate successive Di values for a few iterations. In most cases, this 
converges very rapidly. 
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8) Calculating A From System Statistics 

The preceding section derives a formula for the timer delay value which is a function of 
B, T, and A. B is a constant (for a given release of the operating system). T is 
measurable from the system. It remains to describe how A can be calculated 
dynamically. 

Define the following terms: 

R -The frequency with which the Group Commit Buffer is written. The system can 
trivially maintain statistics to provide this. 

Usus - The total system work. This is represented by the CPU utilization. Again, the 
system can trivially maintain statistics to provide this. 

As discussed above, all of the work for transactions running on the system may be 
considered to be divisible into two parts: A and B. B is the cost of writing a commit 
buffer. A is the remaining cost of the transaction. 

This means that we can consider the work performed by the system to have two 
components: 

U sys = ( R * B ) + Other transaction work 

The other transaction work may be averaged among the transactions processed during the 
sample interval. This implies that: 

Other transaction work = (A * T) 

This leaves us with: 

U sy8 = (R*B) + (A*T) 

Where R, U S ys, and T are measurable and B is a constant. Rearranging things leaves us 
with: 



A = 



U Bys - (R * B) 
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9) The Effect of Group Commit Timers on Throughput 

To learn about the effects of Group Commit timers, we set up some spread sheets to plot 
throughput verses response time for a number of artificial transactions. In the first, we 
assumed that: 

A =100 Milliseconds 

B =50 Milliseconds 

L =33 Milliseconds 

This nicely models a machine in which a relatively low transaction rate is achieved on a 
single processor. This gave us the following results: 
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System Throughput vs. Response Time -- Trial 1 
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Next, we tried to analyze what would happen if the clock Tate of the machine was 10 
times as great This would give us: 

A ■ 10 Milliseconds 

B m 5 Milliseconds 

L « 33 Milliseconds (remember, L is wall clock time) 
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Notice that the dramatic results ire a consequence of the ratio between A and B (which is 
what we experience on our machine). If you change this ratio because you have extra 
good logging or you have larger transactions, the effect is present, but not as pronounced. 
Let's try: 

A -100 Milliseconds 



B 



= 10 Milliseconds 



33 Milliseconds (remember, L is wall clock time) 
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10) Testimonial 

In the Spring of 1987, Tandem gathered 32 of VLX processors together to perform a 
large benchmark as a prelude to the announcement of our NonStop SQL product. When 
we started the benchmark (which consisted of DebitCredittf] transactions with 2 second 
response time), we were not using the Group Commit Timers. Running with timer values 
of zero, we were able to process 165 transactions per second. 

After performing some "back-of-the-envelope" calculations, the Group Commit Timer 
was set. By using the Group Commit Timer (and the Audit Flush Timer discussed below 
in section 1 1), we were able to process 208 transactions per second with 2 second. 



11) Future Research 

A number of other applications for dynamic timers have been discussed amongst our 
cohorts. The idea of Group Commit Timers is an approach that is not specifically related 
to Group Commit. The idea works whenever you have multiple activities which could be 
accomplished more efficiently if bundled together into one unit of work. 

Some ideas that have come to mind include: 



Timers and Message Based Systems 

The Tandem system is a distributed multi-processor system. The various CPUs 
communicate with each other by sending messages. Currently, somewhere in 
excess of 20% of our machine cycles are spent sending messages. 

The overhead for sending a message has two components: a "per-message" 
overhead and a "per-byte" overhead. If we could bundle multiple messages into a 
single transmission, some of the "per-message" overhead cost could be amortized 
over the messages that were bundled. 



Timers for Data Communication 

Most of the data communications protocols have large overheads associated with 
each transmission. By bundling multiple messages going in the same direction, 
into a single transmission, many CPU cycles could be saved. 

As with Group Commit, the savings associated with increased sharing of the same 
work could reduce the response time of the work enough to justify hanging 
around for a while to see if anyone else wants to hitch a ride. 
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• Audit Flush Timers 

The Tandem system is a distributed system in which the before and after audit 
images for database updates are frequently generated and buffered in a CPU that 
is not physically connected to the disk holding the log[ 4 -5]. To commit a 
transaction, this audit must be transmitted to one of the CPUs that is physically 
connected to the Log disk. 

We have found that significant savings may be obtained by using timers to delay 
the transmission of the audit images for a while. When timers are used here, the 
buffer that is sent will contain the audit images for more transactions that are 
ready to commit. 

• Lock Release Timers 

This was an idea that didn't work. In the Tandem system, the record locks on the 
database are maintained in the process that manages die disk containing the 
records being locked. To release the locks, the system must dispatch the disk 
process. We tried to see if by delaying the dispatch of the disk process, we could 
cause the disk process to release die locks for multiple transactions at the same 
time. 

Well, it would release the locks for multiple transactions at the same time, but the 
CPU savings weren't worth the increased lock contention. Oh, well. 

11.1) Shepherds 

As discussed above, the Tandem system is already employing two timers that affect the 
life of a transaction. We are considering the possibility of adding more. 

When one function controlled by a timer may be begun as soon as another function 
controlled by a timer completes, a token (or Shepherd) may be passed as each function is 
processed. Even if the second function (e.g. the Group Commit buffer flush) must wait 
for a bunch of completions of the first function (e.g. Audit Flush from all of the 
constituent processors), the shepherd may be used. 

The basic advantage to this approach is that you can get savings by sharing the work of 
all of the various functions while only delaying for the processing of the first function. 
Once the first function starts, you, your other transactions, and the shepherd will get 
immediate service from the remaining functions. 

Our guesstimates indicate that shepherds come out dead even with multiple timers on our 
system in which two levels of timers are employed. Once we start bundling more of the 
system functions into activities that can be simultaneously performed for multiple 
transactions, shepherds will be looked at even more closely. 
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11.2) A Minor Anomaly 

When we went to model the number of transactions in a Group Commit buffer when non- 
zero timers are used, wc found that the number was worse than the zero timer cases in a 
very small range (this effect is visible in Figure 6). The problem occurs at low 
transaction rates when timers are first enabled and the timer value is still smaller than L 
(the wall clock time to do a log I/O). At this point, our Response Time model ceases to 
be valid. 

We decide not to worry about this at this time and chose, instead, to restrict the system to 
behave as if the timer value was zero when the calculated optimal timer value was 
smaller than L. 
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This is assuming the following values: 
L - .033 seconds 
A - .010 seconds 
B - .005 seconds 
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12) Conclusions 

Group Commit timers have been shown to provide very noticeable increases in 
throughput while still meeting response time objectives. They offer a surprising gain for 
a modest amount of implementation. 

We feel quite strongly that timers are important. The arbitrary selection of a specific 
value for the timer could harm some transaction mixes. An example of this would be a 
system running serialized batch transactions. The use of a non-zero timer will only add 
to the response time. To expect a system manager to wisely select an appropriate timer 
value is also untenable. For these reasons, it seems clear that the system should 
dynamically calculate an appropriate timer value based on the system load. 

While more work is needed to perfect the model, we feel comfortable using these 
formula in our production software to calculate the Group Commit Timer value. 
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A) Appendix A: Hieroglyphics 

This appendix fills in all of the "leaps of faith" that have been made in the rest of the 
paper. 

A.1) Calculate C 

As described in section 5.1, the formula for the expected Group Commit Buffer 
population (Co) when no timers are used is: 

Wj+WdCod 
C = 



W t 

A.1.1) Calculate Coa 

The calculation for Cw is almost identical to the calculation for Q. The only difference is 
that the time to accumulate transactions is not D, but L (the service time on a log I/O). 
Following the same arguments as those presented for C d , we have: 

Expected records per delayed write 

Cod=- 



Probability that a delayed write occurs 
Which is: 

X iP LT (i) 

i-1 

Cod= 



I P LT 0) 

i-1 



Note that: 



IiP LT (i)= IiP LT (i) 

i-1 i=0 



This is because when i = 0, 0Pi(LT) equals 0. But note that: 

oo 



X iP LT (i) = LT 



LT 
i-0 
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Hence: 



X iP LT (i) = LT 

N1 



Now we observe that: 



S P LT (i) = 1 - Plt(O) 

W1 



This means that: 

LT 



1 - P LT (0) 

A.1J2) Calculate W d 

The number of delayed writes to the disk is somewhat complicated to compute. A 
delayed write occurs whenever a log write finishes and 1 or more transactions is waiting 
to commit. These transactions must have arrived while the log I/O was outstanding (or in 
the time interval L). The probability that one or more transactions is waiting can then be 
expressed as: 

(1 " Plt(O)) 

This means that the number of delayed writes is: 

W d = W, (1 - P LT (0)) 

(Wi + W d )(1-P LT (0)) 

Wi(1 - Plt(O)) + W d (1 - Plt(O)) 

Wj(1 -PLT(0))+W d -W d PLT(0) 

So: 

W d P LT (0) =Wi(1-P LT (0)) 



W d 



Wj(1 - P L t(0)) 
Plt(O) 
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A.1.3) Calculate W, 






Let's start out with: 






W t 


= 


Wi + Wd 






= 


Wi(1 - Plt(O)) 

Wj+ 

Plt(O) 




= . 


WiP LT (0) 
Plt(O) 


Wi(1 - Plt(O)) 
Plt(O) 


Giving us: 








W,= 


Wi 


1 




Plt(O) 




Which means 


;that: 






W i = 


W t P L T(0) 





A.1.4) Put Co Together 

Now that we know both Cm and Wa, we can calculate that: 

LT 



W d Cod = W t (1 - Plt(O)) 

(1 - Plt(O)) 

= W t LT 
Next, we recall that 

Wj+WdCod 



Co = 



Substituting gives us: 

W t P L T(0) + W t LT 



C = 



= Plt(0) + LT 

Now, we have to look in our textbooktPREss] to tell us the value of the Poisson 
Probability Function. According to the magic formula in the book, 

Px (0) = e-* 
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Hence, 

Plt(O) = 0-lt 
And we get: 

Co = LT + e-LT 

A.2) Calculate C d 

The calculation for Cd is almost identical to the calculation for Cm. The only difference is 
that the time to accumulate transactions is D when calculating Q and L (the service time 
on a log I/O) when calculating Cm. For this reason, the discussion here and in section 6.1 
is almost identical to the discussion in sections 5.1 and A. 1.1. 

In section 6.1, we determined that: 



c t = 


X IPtdO) 

i=1 










I P TO (i) 
i=1 




Note that: 








■SIPtdO) 
i-1 


= i iptd(o 

i-=0 



This is because when i = 0, 0Pi(TD) equals 0. But note that 



S iP TD (i) = TD 

i=0 
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Hence: 



IiP TD (i) =TD 

i-1 



Now we observe that: 



TO 



This means that: 

TD 



I Ptd(') = 1 * p TD(0) 



C d = 

C d = 



1 " Pto(O) 

TD 
1 -e-TO 



A.3) Calculate R4 

As described in section 6, R<i is: 

(A + B) 

Rd = + D/2 

(1 - U d ) 

Substituting for Ud (again described in section 6) we have: 

(A + B) 
Rd= +D/2 



+ D/2 



+ D/2 
C d - TACd - TB 

Substituting for Q (described in section 6.1) yields: 

ATD/(1 - e--ro) + BTD/(1 - e-TD) 

R d = +D/2 

TD/(1 - s-td) - T2AD/(1 - e-TD) - TB 



1 - T(A+B/C d ) 


(A + 


B) 


1 -TA 


- TB/Cd 


CrfA* 


C d B 
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Multiplying above and below by (1 - e " TO ) yields: 

ATD + BTD 

R d= + D/2 

TD-TzAD-TB + TBe-TD 



AD + BD 



D-TAD-B + Be-TD 



+ D/2 



A.4) Calculate Rd' 

Let's make the following assignments: 

f = AD + BD 

g = D-TAD-B + Be-TD 
Then we have: 

f g - «&' 

FV= + 1/2 

9 2 

f = A + B 

g'= 1-TA-TBe-TD 

f g = (A + B)(D - TAD - B + Be -td) 

= AD - TA2D - AB + ABe -td + BD - TABD - B2 + B2e -td 

fg' = (DA + DB)(1 - TA - BTe -td) 

= AD - TA2D - ABTDe -td + BD - TABD - B2TDe -td 
So, when we combine fg and fg' we get: 

fg - fg' = AD - TA2D - AB + ABe -td+ BD - TABD - B2 + B2e -td 

- AD + TA2D + ABTDe -td - BD + TABD + B2TDe -td 

- AB - B2 + ABe -td + B2e -td + ABTDe -td+ B2TDe -td 
(A + B)(-B + Be -td + TBDe -td) 

B(A + B)(TDe -td -1 + e -td) 
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Now, we can assemble R d ' as: 



f o - fg' n 

Rd' = + 1/2 

g 2 

B(A + B){TDe-TD-i +©-td) 

= + 1/2 

(D-TAD-B + Bs-td)2 

A.5) Solve for D When (R d ' = 0) 

Now, we are going to attempt to solve for Rd' = 0. We do this by assuming that Rd' = 
and munching around with the equation. 

B(A + B)(TDe-TD-1 +e-TD) 

R d '= +1/2 

(D-TAD-B + Be-TD)2 

B(A + B)(TDe-TD-l + e-TD) 

= + 1/2 

(D-TAD-B + Be-TD)2 

So this gives us: 

B(A + B)(TDs-td-1 + ©-td) 

-1/2 = 

(D-TAD-B + Be-TD)2 

(D - TAD - B + Be-TD)2 = - 2B(A + B)(TDe -td -1 + e -td) 

( D(1 - TA) - B(1 - e -td) )2 = 2B(A + B)(1 - e -td - TD© -td) 
Taking the square root of both sides we have: 



D(1-TA) - B(1-e -td) = V( 2B(A + B)(1 - e - TD - TDe -td) 



D(1-TA) = B(1 -e -td) + V( 2B(A + B)(1 - e " TD - TDe -td) 



B(1 - 6-td) + V( 2B(A + B)(1 - e' 10 -TD©-td) ) 

D= 

1 -TA 
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A.6) Calculating Y and Y' 

We take the following equation from section A.5 above. 

(D - TAD - B + Be -td)2 = - 2B(A + B)(TDe -to -1 + e -td) 
Modifying this slightly we have: 

= (D - TAD - B + B©-td)2 + 2B(A + B)(TDe -td -1 + e -td) 
Let's define a function Y as: 

Y = (D - TAD - B(1 - e -td)2 + 2B(A + B)(TDe -td -1 + e -td) 

The function Y has a value of exactly when IV = 0. Therefore, if we find the value for 
D that causes Y to equal 0, we will have found the value for D which causes Rd' to equal 
0. This value for D is the optimal value for the timer. 

So, as mentioned above in section 7.2, we need to find Y' to use the Newton-Raphson 
method to approximate where Y = 0. Let's rearrange Y slightly to get: 

Y = 2B(A + B)(TDe -td - 1 + e -td) + ((1 - TA)D - B(1 - e -td)) 
And we get: 

Y = 2B(A + B)(Te -td - T2De -td -Te -td) + 

2((1 - TA)D - B(1 - e-TD))(i - TA - TBs-td) 

Y m 2( (1 - TA)D - B(1 - e-TD)) (1 - TA - TBs-td) 

- 2B(A + B)T2De-TD 
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